Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 163-172: Update the fenced code blocks in
workflows/cve-fixer/.claude/commands/cve.fix.md to satisfy MD031/MD040 by adding
explicit language identifiers (e.g., ```text for the plain table and ```bash for
the shell block) and ensuring there is a blank line before and after each fenced
block; locate the blocks using the existing fence markers (``` and ```bash) and
the shown content ("upstream  llm-d/..." table and the "# Clone once:" shell
example) and insert the missing blank lines and the language tag on the opening
fence for each block.
- Around line 174-179: The branch naming guidance is inconsistent: the
multi-branch example uses a target-branch token (e.g.,
fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1) but the canonical rule later
omits it (fix/cve-...-<package>-attempt-1), risking collisions across base
branches; update the canonical naming rule to include a target-branch
placeholder (e.g., <target-branch> or the actual base branch name) and make both
the example and the canonical pattern consistent so every fix branch (symbols:
fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-N) uniquely identifies the
base branch and prevents reuse/overwrite when repeating steps 4–11 for each
branch.
- Around line 183-191: The current flow that "Clone the repo once" then loops
over TARGET_BRANCHES (steps 5–11) can leak state between branch iterations;
update the procedure so each target branch runs in an isolated workspace: for
each branch in TARGET_BRANCHES either (a) create a fresh clone (git clone into a
new REPO_DIR per branch) or (b) perform a strict reset (git fetch --all; git
checkout <branch>; git reset --hard origin/<branch>; git clean -fdx) before
applying fixes, and ensure git credentials configuration (gh auth setup-git /
credential.helper / SSH fallback) is applied for each cloned workspace so
pushes/PRs cannot be affected by artifacts, uncommitted changes, or lockfile
drift from previous iterations.
- Around line 155-159: The TARGET_BRANCHES array construction can include
duplicates if ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; change the logic
that sets TARGET_BRANCHES (the branch assembly around TARGET_BRANCHES,
DEFAULT_BRANCH and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before use —
for example, build TARGET_BRANCHES by iterating DEFAULT_BRANCH and each element
of ACTIVE_RELEASE_BRANCHES and only appending branches not already present (or
use a temporary associative set) so TARGET_BRANCHES contains unique branch names
and avoids duplicate PR attempts.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 83-87: Insert a single blank line before the fenced code block in
the "a. Set up variables (AUTH already set from Step 2):" list item so the
markdown has a blank line immediately before the ```bash fence (fixing MD031).
Locate the fenced block in workflows/cve-fixer/.claude/commands/cve.find.md
under the "COMPONENT_NAME" setup section and add the blank line above the
```bash line to make the block compliant.
- Around line 69-75: The fenced code block starting with "```bash" containing
the export lines currently lacks surrounding blank lines (MD031); add one blank
line immediately before the opening "```bash" and one blank line immediately
after the closing "```" so the code block is separated from the surrounding list
text (update the block in workflows/cve-fixer/.claude/commands/cve.find.md where
the export JIRA_API_TOKEN/JIRA_EMAIL lines appear).
- Around line 58-79: The curl healthcheck using JIRA_BASE_URL and TEST_RESPONSE
should not treat HTTP 403 as "insufficient permissions" because
/rest/api/3/myself returns 401 for both auth failures and permission issues;
update the logic that branches on TEST_RESPONSE to consolidate 401 handling (log
both missing/invalid creds and insufficient permissions together and instruct
the user to check API token/email and permissions) and remove or disable the
separate 403 branch, or alternatively replace the endpoint with a
permissions-specific endpoint if you really need to distinguish 403; keep the
existing note about not pre-checking env vars (do not add a [ -z
"$JIRA_API_TOKEN" ] check).
- Around line 58-77: The documentation says to "retry once" on network/timeout
but the TEST_RESPONSE curl call lacks retry options; update the curl invocation
that sets TEST_RESPONSE (the command using JIRA_BASE_URL and AUTH) to perform a
single retry on transient failures by adding curl retry flags (e.g., --retry 1
plus an appropriate --retry-delay and --retry-connrefused) while preserving
existing timeouts (--connect-timeout, --max-time) and the exit-code capture (-s
-o /dev/null -w "%{http_code}"); ensure the adjusted curl still returns an HTTP
status code into TEST_RESPONSE so the subsequent HTTP 200/401/403/Other handling
continues to work.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 153-160: The TARGET_BRANCHES assignment can produce duplicates
when ACTIVE_RELEASE_BRANCHES includes DEFAULT_BRANCH; update the logic that
builds TARGET_BRANCHES (the block using REPO_TYPE, DEFAULT_BRANCH and
ACTIVE_RELEASE_BRANCHES) to deduplicate entries before further processing — for
example, after composing TARGET_BRANCHES, iterate and rebuild a new array using
a seen set (declare -A seen) to skip already-added branch names so each branch
appears only once; ensure downstream consumers of TARGET_BRANCHES use the
deduplicated array.
- Around line 162-173: The fenced code block for the "llm-d inference-scheduler"
example is missing a language identifier and blank-line framing; update the
markdown by adding a blank line before and after the triple-backtick fence and
include a language token (e.g., "text") after the opening ``` so the block
around the "upstream llm-d/llm-d-inference-scheduler ..." example is fenced as
```text ... ``` to satisfy MD031/MD040.
- Around line 206-207: The workflow currently sets a single REPO_DIR and then
iterates branches using checkout loops, which causes state leakage; modify the
flow so each target branch performs an independent clone into its own temporary
directory (create a fresh REPO_DIR per-target inside the per-target loop),
perform git checkout, run the fix/test/PR sequence, and then clean up that temp
clone; update mentions of REPO_DIR, the per-target loop, and any checkout logic
to reflect per-target isolated clone→checkout→fix→test→PR execution and ensure
cleanup after each target.
- Around line 174-178: Update the canonical branch-naming pattern to include the
<target-branch> token so it matches the earlier examples; specifically change
the canonical example `fix/cve-...-<package>-attempt-1` to the consistent
pattern used above `fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-1` (or
equivalent ordering used in the Multi-repo + multi-branch examples) and update
any other occurrences in the document so all examples and the canonical section
use the same `<target-branch>`-inclusive format to avoid cross-branch
collisions.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 439-443: Update the output/reporting docs to reference the new VEX
artifact names and flows instead of the old "already-fixed" wording: replace
references to `artifacts/cve-fixer/fixes/vex-justified-CVE-YYYY-XXXXX.md` and
any mentions of the old “already-fixed” flow with the corresponding new artifact
names (`vex-justified-*`, `vex-needs-human-review-*`) and update the
printed/report messages (e.g., the "✅ CVE-YYYY-XXXXX not present..." line) and
the bullet list for the auto-determined justification cases to explicitly
document writing the correct VEX artifact and leaving closure to a human
reviewer.

---

Outside diff comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 36-46: The docs mention the --ignore-vex flag but never instruct
storing it; update the behavior notes so --ignore-vex is persisted as a boolean
just like --ignore-resolved (e.g., document IGNORE_VEX alongside
IGNORE_RESOLVED), and clarify Step 3’s IGNORE_VEX branch to read that boolean
when filtering results; ensure the instruction still forbids using
AskUserQuestion or presenting options and that component prompting remains
unchanged.

---

Duplicate comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 72-76: Add a blank line before and after each fenced bash code
block that contains the export lines (the block starting with the URL
"https://id.atlassian.com/manage-profile/security/api-tokens" and the block with
"export JIRA_API_TOKEN" / "export JIRA_EMAIL") so the fenced blocks have an
empty line above and below to satisfy MD031; update both occurrences (the block
containing the export lines and the later duplicate block) accordingly.
- Around line 62-78: The auth probe using GET
"${JIRA_BASE_URL}/rest/api/3/myself" is inconsistent: it documents a special
HTTP 403 case and “retry once” but the curl invocation (TEST_RESPONSE) has no
retry behavior and the endpoint may not reliably differentiate 401 vs 403 for
auth issues; update the logic around TEST_RESPONSE to either consolidate 401/403
handling for auth failures or switch to a permission-specific endpoint if you
need to detect permission vs credential problems, and explicitly implement a
single retry (using curl retry flags or a coded retry loop) when handling
network/timeout responses so the documented “retry once” matches actual
behavior; ensure messages reference TEST_RESPONSE and the "/rest/api/3/myself"
probe so maintainers can find and update the probe logic.

In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 239-258: The documentation section "4.3: Branch loop" currently
describes a single cloned workspace iterating over TARGET_BRANCHES and may leak
state; update the text to reflect the intended independent-per-branch execution
model by removing or clarifying the "Clone once" example and the shared
workspace loop (steps 5–11) and instead describe that each TARGET_BRANCH run
should perform its own checkout/pull/apply-create-PR cycle in an isolated
workspace (or explicitly document the alternative "clone once" mode as a
separate, stateful option), referencing the TARGET_BRANCHES loop and the
checkout/pull/apply PR steps to ensure readers know to avoid shared-state side
effects between branch runs.
- Around line 174-178: The branch naming guidance is inconsistent: the
multi-branch section requires branch-qualified names (example
`fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1`) but the canonical naming
rule later omits the `<target-branch>` component, risking name collisions;
update the canonical rule to include `<target-branch>` (or a `<base-branch>`
token) so it matches the multi-branch example and ensure all references to the
canonical rule and examples use the same format including the branch qualifier.
- Around line 153-160: The TARGET_BRANCHES assignment can yield duplicates when
ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; update the logic that builds
TARGET_BRANCHES (the branch selection block using TARGET_BRANCHES,
DEFAULT_BRANCH, and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before using
them — for example, after composing the array, filter it to unique values (using
an associative "seen" map loop or a stdout-unique transform like sort -u/awk)
and reassign the cleaned list back to TARGET_BRANCHES so no duplicate PR targets
are attempted.
- Around line 163-172: The fenced code examples lack language tags and
surrounding blank lines, which triggers MD031/MD040; update each triple-backtick
block (e.g., the block starting with "upstream  llm-d/llm-d-inference-scheduler 
→ PR against: main" and the other occurrence around the content referenced as
473-481) to add an appropriate language tag (like ```text or ```bash)
immediately after the opening backticks and ensure there is a blank line before
and after the fenced block so the markdown linter accepts the examples; apply
this change consistently to all similar fenced blocks in the document.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 511-516: The curl payload is built by directly interpolating
${COMMENT}, creating unsafe JSON; instead generate a properly escaped JSON body
(for example using jq or another JSON encoder) and pipe it into curl so you
don't interpolate ${COMMENT} into the -d string. Replace the inline -d
"{\"body\": \"${COMMENT}\"}" usage in the block that constructs AUTH and calls
curl (refer to variables AUTH, COMMENT, JIRA_BASE_URL, JIRA_KEY) with a safe
encoder step such as: create the JSON via jq -n --arg body "$COMMENT"
'{body:$body}' (or equivalent), then pass it to curl with --data `@-` (or -d `@-`)
so the comment is JSON-escaped and newline/quote characters cannot break the
payload.
- Around line 423-424: The pipeline currently assigns AVAILABLE_TAGS from the
skopeo command without checking failure; capture skopeo's exit status (or run it
in a subshell storing both output and exit code) when populating AVAILABLE_TAGS,
and if skopeo fails (non-zero exit) log a clear error and fail/exit the job (or
set a distinct error flag) instead of continuing with an empty AVAILABLE_TAGS;
update the code that references AVAILABLE_TAGS to rely on this failure handling
so you don't treat an empty list from a failed skopeo call as "no newer tags
available."
- Around line 246-258: Split the combined example into two clearly labeled
scenarios so operators don't confuse repositories and steps: update the block in
workflows/cve-fixer/.claude/commands/cve.fix.md to (1) label and describe
"Scenario 1: User has write access" (or "Push directly to origin") with the
/tmp/red-hat-data-services/llm-d-inference-scheduler clone and its five PR
targets (main, rhoai-3.3, rhoai-3.4, rhoai-3.4-ea.1, rhoai-3.4-ea.2), and (2)
label and describe "Scenario 2: User lacks write access (upstream repo)" (or
"Push to fork") with the /tmp/llm-d/llm-d-inference-scheduler clone and the
single fork-based PR example (head: <user>/llm-d-inference-scheduler:fix/... →
base: main); ensure each scenario is wrapped in its own fenced bash block and
update the inline comments to "Push directly to origin, create 5 PRs" and "Push
to fork, create 1 PR" respectively.
- Around line 483-485: The script calls an undefined helper version_is_safe when
evaluating PACKAGE_VERSION against CVE_AFFECTED_RANGE which will crash at
runtime; add a version_is_safe function (or replace the call) that accepts
(pkg_version, affected_range) and returns success (0) when the package version
is not in the affected range and failure (non‑zero) when it is, then keep the
existing logic that sets VEX_JUSTIFICATION="Vulnerable Code not Present" and
VEX_EVIDENCE using PACKAGE, PACKAGE_VERSION and CVE_AFFECTED_RANGE; reference
the symbol version_is_safe and ensure it is available before the conditional
that uses PACKAGE_VERSION and CVE_AFFECTED_RANGE so the branch executes
correctly.
- Around line 427-428: The awk comparison '$0 > cur' used to compute NEWER_TAGS
from AVAILABLE_TAGS compares strings lexicographically and breaks for semantic
versions; replace that step with a version-aware filter: sort AVAILABLE_TAGS
with sort -V and then select only entries that are semantically greater than
CURRENT_TAG (or run a short Python snippet that uses packaging.version.parse or
similar to compare each tag to CURRENT_TAG) so NEWER_TAGS contains only tags
with higher semantic versions; update the code that references NEWER_TAGS,
AVAILABLE_TAGS and CURRENT_TAG accordingly.
- Around line 488-490: The existing conditional that uses SCAN_OUTPUT and
PACKAGE in the elif branch wrongly checks for "No vulnerabilities found" and
will never match the intended scenario; update the conditional in the
conditional block that sets VEX_JUSTIFICATION/VEX_EVIDENCE to instead detect a
govulncheck informational vulnerability with no call stacks by using: check that
SCAN_OUTPUT contains "Vulnerability #" and the "${PACKAGE}" string and that it
does NOT contain "Call stacks" (e.g., replace the elif with: elif echo
"$SCAN_OUTPUT" | grep -q "Vulnerability #" && echo "$SCAN_OUTPUT" | grep -q
"${PACKAGE}" && ! echo "$SCAN_OUTPUT" | grep -q "Call stacks"; then), or
alternatively change the scan invocation to emit JSON (-json) and parse the JSON
output for findings without call traces for more robust detection.

---

Duplicate comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 153-160: TARGET_BRANCHES can contain duplicates when
DEFAULT_BRANCH also appears in ACTIVE_RELEASE_BRANCHES; update the assignment
logic for TARGET_BRANCHES (the variable) to deduplicate entries after assembling
from DEFAULT_BRANCH and ACTIVE_RELEASE_BRANCHES: build the initial list as
currently done, then iterate and push each branch into a new deduped array only
if not already present (use a shell associative map or membership check) so
TARGET_BRANCHES ends up with unique branch names.
- Line 628: Update the canonical branch-naming rule to include the target branch
to avoid collisions: change the rule string from
"fix/cve-YYYY-XXXXX-<package-name>-attempt-1" to a pattern that includes the
target branch (for example matching the existing example
"fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1"); ensure any validation or
generation logic that uses the symbol/name pattern (branch naming rule, branch
creation logic) is updated to accept and produce the target-branch token so
multiple target branches produce distinct branch names.
- Around line 163-172: The fenced code block containing the lines starting with
"upstream  llm-d/llm-d-inference-scheduler" is missing a language tag and
surrounding blank lines; update the block to use a language identifier (e.g.,
```text) and ensure there's a blank line before the opening ```text and a blank
line after the closing ``` so the block complies with MD040/MD031 rules.